\documentclass{article}
\usepackage{graphicx}
\usepackage{dot2texi}
\usepackage{tikz}
\usetikzlibrary{shapes,arrows}
\usepackage{listings}
\bibliographystyle{plain}
\definecolor{CodeColor}{rgb}{0,0.08,0.45}
\newcommand{\code}[1]{\texttt{\textcolor{CodeColor}{#1}}}


\begin{document}

% Define layers
\pgfdeclarelayer{background}
\pgfdeclarelayer{foreground}
\pgfsetlayers{background,main,foreground}


\section{Scientific Testability}

The concept of \emph{Testability} is one of the fundamental aspects of science. Given a phenomenon and a hypothesis that seeks to explain the phenomenon, the hypothesis has to be \emph{testable} in order to be a scientific hypothesis. This is what sets it apart from non-scientific hypothesis, such as 'An Intelligent Designer created the Earth and all life according to biblical law' or 'If we add 1 GB of RAM to our server, we can double the amount of concurrent transactions that can be processed'. 
% insert typical software hypothesis, which is outragoues but common.. Pointen er at hvis systemet ikke er testbart, er alle hypoteser om systemets opførsel per definition uvidenskabelige!
In the scientific method predictions are formed from hypothesis which serve as the basis of particular tests or experiments. A defining characteristic of scientific tests are repeatability which demands isolation from the surrounding environment \cite{chalmers}.

Being able to isolate instances of objects for test purposes requires pre-planning, discipline and a knowledgeable class designer. In listing \ref{consdep} \code{class A} has a dependency on \code{B} which makes any hypothesis involving \code{A} untestable in isolation from \code{B}.

\begin{lstlisting}[label=consdep]

class A 
 public A()
  new B()

\end{lstlisting}

Any test of \code{A} includes some execution of \code{B}. Thereby making any experiment with \code{A} harder to reason about since we have no control of instance \code{B}. This leads us to the concept of \emph{observability}. Validity of a hypothesis depends on one or more tests, the outcome of which must be observable. 
Using the wellknown design pattern Dependency Injection (DI) \cite{fowler2004inversion} lends us a different design:

\begin{lstlisting}[label=di]

class A 
 public A(B b)

\end{lstlisting}

This gives us control of the instance \code{b} enabling us to supply a test version instead which makes it possible to observe the interaction of \code{a} with \code{b}.

The unittest from listing \ref{unittest1} lends itself to the following interpretation. The system under test is the object \lstinline+sut+ on which we perform the experiment \lstinline+sut.foo(input)+. The observable \lstinline+result+ is then tested against the hypothesis \lstinline+IsTrue+.

% giv testen et bedre navn..
\begin{lstlisting}[label=unittest1]

void test()
 var input = 2
 var result = sut.foo(input)       // Observable result
 Assert.IsTrue(result.bar)    // Hypothesis is tested

\end{lstlisting}

% hvordan kommer vi fra example based unit testing til en hypotese!!


%% what are static guarentees in this context
Static guarantees (or predictions!) given by a type-system can be seen as facts concerning program behaviour. Whereas unit tests are example based, type system facts concern all possible instances. 

%% dependent type systems 

In a typical mainstream type system such as Java, every reasoning process involving the return type \verb+T+ of a method \verb+m+ must in most cases include the full space of \verb+T+. That is \verb+T = {T, null, exception}+, so in reality the prediction \verb+T+ given by the signature of \verb+m+ is a very imprecise one.   


In the conceptual framework of the scientific method \emph{Code Contracts} \cite{meyer1992} positions itself between the sparse, statically validated, predictions of a type system and the more general unit tests which enables predictions involving several software components and are only as valid as the next test run dictates. The predictions expressed by a code contract involves a fairly limited space of possible phenomenons, such as \verb+Contract.Ensures(Method.Result > 4)+. This space is larger than the type system guaranteed prediction \verb+int Method+ but smaller than a unit test that takes into account interactions with other methods.

Increasing the testability of a software component increases the set of hypothesis that can be tested and validated or rejected. This increases the possible scientific knowledge that can be acquired and enables the transformation of unscientific hypothesis into scientific ones.
Zero testability means almost no hypothesis of interest can be accepted or rejected.

% Important point: testability is just as important as encapsulation..


\section{Methods and testability}

We define testability of methods as the degree to which hypotheses targeting the methods can be rejected or accepted.
The testability of an isolated method is determined by its signature:


\begin{enumerate}
\item \label{mt:1} $m(o_1) \to o_2$. The result of $m$ is observable. Therefore $m$ is testable.
\item \label{mt:2} $m() \to o_1$. Even though $m$ allows no input, the result $o_1$ is still observable. $m$ is therefore testable.
\item \label{mt:3} $m(o_1) \to ()$. Maybe indirectly observable through $o_1$. So $m$ might be testable. 
\item \label{mt:4} $m() \to ()$. We cannot observe the outcome of any tests directly. Therefore $m$ is not testable in \emph{isolation}.
\end{enumerate}

If we wish to increase the testability of our methods we should prefer \ref{mt:1} and \ref{mt:2} while avoiding \ref{mt:3} and \ref{mt:4}. This includes refactoring of the kind $m(o_1) \to ()$ into $m(o_2) \to () \circ m(o_1) \to o_2 $. Which splits the method $m$ into testable parts. In other words, favor function composition as opposed to large monolithic methods with a procedural flavour.

In order to test $m() \to ()$ we need some observable or controllable $o$ which participates or is the result of the execution of $m$. 

%TODO: Definer testbar og definer testbar i isolation. For sidstenævnte er objekt grafer relevante..

\section{Object Ownership Graphs}

%% Enumerate?
A method can have 4 shapes: $m(o_1, \ldots, o_n) \to o_{n+1}$, $m() \to o_1$, $m(o_1, \ldots, o_n) \to ()$ or $m() \to ()$.

An object $o$ is defined by a set of methods $M=\{ m_1, \ldots, m_n \}$ and a set of fields $F=\{f_1,\ldots,f_2\}$.
% tror ikke vi får brug flere fields, men måske bare et lager (store)..
Fields are only visible to the object itself. Methods are allowed to assign new objects or objects passed through formal parameters to fields. Fields are only exposed through methods.

A directed object graph $G = (V,E)$ consists of a given \emph{composition root} and any number of object vertices. The root is itself an object. An edge $(o_1,o_2, m(o_2) \to ()) \in E$ represents \emph{ownership} of an object with the destination $o_2$ being the owned object and the origin $o_1$ being the owner. 

TODO: gælder ovenstående også når vi retunerer et objekt? hvad med private metoder der returnerer og public?

The edge label, e.g. $m(o_2) \to ()$ indicates the method invocation responsible for establishing the ownership. Ownership can be established by the creation of a new object or \emph{transferred} from another object through a formal parameter.
In other words the edges can be seen as links between object instances with new links being created via method calls. Ownership might be lost at the end of a method invocation or live longer via a field assignment

% er ownership passende? vi mener CURRENT ownership.. brugt evt. control 

How objects are created is not relevant to the model. The model handles both class based languages and prototypical ones. 

% Can an object be owned by more than one? multithreading..

Initial objects are created by invoking a special entry point method on the object root. Further transformations of the graph are made possible by calling any $m \in M$ on the initial objects. Figure \ref{g1} corresponds to the graph created by invoking $m(o_1,o_2);m(o_1)$ on the composition root $o$ followed by the invocation of $m_1$ on $o_1$ resulting in the ownership of $o_6$. 

This is not the only possible invocation outcome. Since the exact logic in some $m$ might dictate another shape of the graph at this point in time.

\label{g1}
\begin{dot2tex}[mathmode, dot, options=--autosize]
digraph G {
node [shape="circle"]; 
o_3;
o_1;
o_r -> o_1 [label = "m_1"];
o_r -> o_3 [label = "m_2(o_3) \to o_5"];  
o_r -> o_5 [label = "m_2(o_3) \to o_5"];
}
\caption{Graph \ref{g1}}
\end{dot2tex}

From the viewpoint of the composition root the object $o_3$ is controllable which means all interaction with $o_3$ is observable. The object $o_5$ is directly observable since it is returned from the method $m_2$. The problematic $m_1$ takes ownership, in this case by creation, of the object $o_1$. $o_1$ is not observable or controllable which might be problematic in regard to testing.


\subsection{Direct Observability And Controllability}

% har vi brug for at differentiere imellem obs og cont?

% transitive relationer?

% skal disse definitioner omhandle hele undertræer (og dermed en hel graf pr inductiv def) eller blot knuder en enkelt kant væk..

% definer først på o, derefter transitiv relation

\paragraph{Directly observable}
Given two objects $o_1$ and $o_2$, $o_2$ is directly observable from $o_1$ if $\exists (m \to o_2) \in M_{o_1}$.

The transitive closure gives an observable path. Such as:

\label{g2}
\begin{dot2tex}[mathmode, neato, options=--autosize]
digraph G {
node [shape="circle"]; 
o_r -> o_1 [label = "m_1 \to o_1"];
o_1 -> o_2 [label = "m_1 \to o_2"];
}
\caption{Graph \ref{g1}}
\end{dot2tex}

Here $o_r$ is able to inspect $o_2$ via $o_1$. 
% korrekt terminologi?
The transitive set represents all objects that can be observed from $o_r$, in other words, all possible output.

\paragraph{Directly controllable}
Given two objects $o_1$ and $o_2$, $o_2$ is directly controllable from $o_1$ if
$\exists m(o_2) \in M_{o_1}$

The transitive closure gives a controllable path.

\label{g3}
\begin{dot2tex}[mathmode, neato, options=--autosize]
digraph G {
node [shape="circle"]; 
o_r -> o_1 [label = "m_1(o_1)"];
o_1 -> o_2 [label = "m_1(o_2)"];
}
\caption{Graph \ref{g1}}
\end{dot2tex}

In the above graph $o_r$ can via the directly controlled $o_1$ supply its own $o_2$ thereby gaining insight into all interaction with $o_2$. In other words all message calls on $o_2$ are observable. The transitive set represents all possible control points where method invocations can be observed.





An \emph{observable message} $m \in G$ is any message send to a controllable instance.

%% TODO: n = {0,...,1 }
An \emph{observable transformation} is a sequence $m_1; \ldots ; m_n$ where $m_n$ results in an observable instance.

\subsection{Object testability}

In order to decide whether an object is testable we must look at its methods. We can characterize all methods according to their signature.
Note that a constructor method corresponds to a method with the signature $() \to ()$ or $(o_1, \ldots, o_n) \to ()$.

\begin{itemize}
\item $m(o_1, \ldots, o_n) \to o_2$.  Is by definition testable. We can control input and observe output.
\item $m() \to o_1$. Is by definition testable.
\item $m(o_1, \ldots, o_n))  \to ()$. Is only testable through any observable message passes or transformations in the resulting object graph created by $m$. %%  this.field = new Foo() .. kan det karakteriseres som et message send til this.field !!? eller har vi brug for observable transformation..
\item $m() \to ()$.  Is only testable through any observable message passes or transformations.
\end{itemize}

%$\forall (m() \to ()) \in M$ there must exist a directly or indirectly observable transformation sequence $.. ; m(); ..$, in order for the method to be testable.

%A directly observable or visible transformation $transf_v$ of an object root $o$ is any transformation $o_1 = o_0::o_i$ where $\exists (m \to o_i) \in o_1$. I.e. the new node $o_i$ in the resulting graph $o_1$ is observable through some method.

\subsubsection{Testable in isolation}

%% alle ikke observerbare instancer

\paragraph{Module definition} 
A module is testable in isolation. An object is a module if all possible graph shapes are testable in isolation. A module may span several objects, if these objects taken together are testable in isolation.

%No true modules exist in most oo languages, since we are allways testing class such as Integer

\section{Testability metric}
%% TODO: message passes skal beskrives i modellen

% Vi får senere hen brug for at definere en sti.

%% Is transf = m(o); o.f = o, where no m:o exist visible? (we need ascii syntax for describing transformations!) .. If not then standard dependency injection pattern in bb, with private fields, not visible..
%% PERHAPS if we call it a TESTABLE TRANSFORMATION instead..


%% Theorem: module overlap only possible when both roots are observable at composition point



%\begin{tikzpicture}[label={fig1}]
%\begin{pgfonlayer}{background}
%        \draw[rounded corners=2em,line width=3em,blue!20,cap=round]
%                (obj.center) -- (f_1.west) -- (f_2.center);
%\end{pgfonlayer}
%
%\end{tikzpicture}




%% Limit the model from previous section as to only allow testable object graphs

% software component = {set of classes that because of dependencies are in necessity always tested together}

\section{Language design for testability}

%% metoder public i klasser som default, men nem mekanisme der exporter public metoder.. 

% If we remove the static environment, we have a bigger chance of maintaining indirectly observable fields!

\bibliography{references}

\end{document}